I wasn't sure where to put the comparison configuration. For some reason it doesn't work if I put it into the workflow folder as I did in HajoRijgersberg/OM#69 (analogous PR for OM).

On https://github.com/jmkeil/qudt-public-repo/actions/runs/2698908908 you can find a preview how the results will look like. The job is marked as failed, because deviations have been found. Deviations can be handled by

• fixing the own ontology,
• fixing the other ontology,
• fixing the mapping (e.g. 6a06b8a#diff-e48e569c0c233b06e9a61b27cf0f6ddedcd8142da4c91bf3d2f8e0debbbbc6b9R715), or
• annotating the other ontologies value wrong in the comparison configuration (e.g. 6a06b8a#diff-e48e569c0c233b06e9a61b27cf0f6ddedcd8142da4c91bf3d2f8e0debbbbc6b9R833, an appropriate snippet is provided in the last column of the result table).

Alternatively, the parameter --failOnDeviation in c904f9b#diff-311f6477bc95af7ccedbe3225a241452ddb76b61cea146f6103c84a5059d6fb8R12 can be removed. Then the job will only fail, if the comparison could not be executed for any reason.

I'm more optimistic. There are different emphases coming from the different projects, so the ontologies choose different pathways through the problem. Nevertheless the results should be equivalent.

The tool merely highlights inconsistencies, which provides an opportunity for further investigation.
Sometimes it will find an error that you had missed, which you can then correct.

It is informative, and I don't see the harm in running it automatically.

I had a look into the documentation and it seems possible to configure GitHub actions for only manually execution. In my opinion, automated execution would be better, as manual executions are more likely to not happen at all. At least in software testing, this is best practice. But, of course, this is your project and your decision. What are your preferences?

We will place the comparison [configuration results] into a folder that isn't included in the release.

Originally posted by @jhodgesatmb in #526 (comment)

What would be the preferred path of the comparison configuration (not results - these do not get committed into the repository)?

The problem as I see it is that there is no baseline ontology that is accepted as the authoritative standard.

@jhodgesatmb: We had this discussion earlier. My answer is still the same. (And I don't have a problem with sticking to our different viewpoints.)

The tool merely highlights inconsistencies, which provides an opportunity for further investigation.
Sometimes it will find an error that you had missed, which you can then correct.

That is the idea behind the tool.

I just updated the comparison configuration, revealing further deviations.

The last update removes deviations obviously caused by OM or SWEET from the result.